在我服務團隊使用 Jira 的情境中，會有兩個 Jira Project，一個是正統意義上的 Product Backlog，專門放產品要開發的待辦事項，而另一個則是放滿 Design 要做的 Task 的 Backlog。

為了避免與 Jira 系統中的名詞搞混，前者我們稱為 Product Backlog，後者我會稱為 Design Backlog，而 Jira 系統中的我會稱為 Jira Backlog。

這時就有一個需求了，我們希望 Product Backlog 中，若某個在 Jira Backlog 中的 Item 需要設計，能夠複製一份到 Design Backlog 的 Jira Timeline 中，讓設計師透過該複本去收納相關的 Design Task。

會有這個需求是因為對 Designer 來說，Design Task 的工作量顆粒度，和 Developer 的 Item Level 相似，而且 Designer 的 Design Task 也會有不同的類別，想要投過 issue type 的圖示視覺化作區分，但是目前 team-management level 的 Jira Project 在 issue type 的客製化只開放在 Item Level。基於這些原因，才有這樣的需求。

為了避免手動複製 Item 的麻煩，這邊就有了自動化的需求。

在實作 Rule 前，我們先到前面提過的 Workflow，去新增一個 🎨 To Design 的狀態。因為想要方便觸發以及表達狀態，我們希望的操作適當狀態改到 🎨 To Design 就會觸發這個複製的 Rule。

記得要到 Columns and statuses 將狀態從左側的 Unassigned statuses 拉到對應的欄位，不然 Rule 中會找不到。若屆時還是找不到，也有可能是系統還沒同步好資料。

另外，在我們的 Design Backlog 的 Jira Project 中，也將 Issue Type 的類別改動完了，這時會發相 Story Item 已經放在第一層的位置了。

接著就開始建立 Rule，使用的 Trigger 為 Issue transitioned，條件是 issue 的狀態移動到 🎨 To Design 時觸發：

接下來就是要來建立能夠複製 Item 到 Design Backlog 的 Action。雖然內建有 Clone issue，但是實務上在跨專案的資料同步上會有些問題，所以這邊不會使用這個 action。

這邊會改用 Create issue 這個 Action。選擇目標專案，以及目標專案下的 Issue Type，也就是 Story Item。

然後為 Summary和 Description 欄位透過右上角的 ... 按鈕，選擇從觸發 Rule 的 issue 複製資料。

接著再建立一個 Link issue Action，然後將關係改成 is cloned by，對象是最近建立的新 issue，也就上一個 Action 所建立的那個。

這樣就完成了，但是為了讓資訊更顯性化，這邊一樣會建立一個發訊息到 Slack 的 Action：

內文如下：

<{{issue.url}}|{{issue.key}} - {{issue.summary}}>
已經被 {{initiator.displayName}} 複製到 Design Board

發布並啟用後，趕緊來測試！這邊選擇將 Item G 的狀態改成 🎨 To Design

來到 Design Backlog 時，就會發現 Timeline 中多了一個 Item。

點進去也看到有成功建立 Issue Link，方便連回原本的 issue 查看最新的資訊。大成功！接下來就可以在下面建立各種相關的 Design Task 了。

Slack 當然也收到了對應的訊息囉